Generally described, many software applications utilize user interfaces (“UI”), such as a graphical user interface, to present and obtain data from a user. A UI generally contains a number of graphical objects whose characteristics and relationship to other UI objects can be defined in terms of an object hierarchy. FIG. 1 is a block diagram of a UI object hierarchy 70 illustrating various objects that may be instantiated in a UI. As illustrated in FIG. 1, the object hierarchy 70 may include an element object 72 that includes a button object 74, an edit box object 76, and an embedded element object 78 that includes a button object 80, a list box object 82 and another element button 82. The object hierarchy 70, in turn, relates to the UI displayed to the user on a computer display. In a typical configuration, a software application utilizes functionality provided by an underlying operating environment to generate each of the application's UI objects.
In one approach to generating application UI, a software application specifies the various classes, properties, and values of the UI objects and their relationship with one another in a programmatic manner, generally referred to as a programmatic UI. A programmatic UI can be implemented by a software developer specifying attributes of each object within the UI in the application's software code. Accordingly, the operating environment obtains the programmatic UI information from the software code and utilizes the information to generate the various application UI. Programmatic UI are inefficient in not facilitating the modification of the various objects utilized in the UI after they have been generated. Moreover, a programmatic UI further does not facilitate the incorporation of all or portions of the software application into a larger, more encompassing software application.
In another approach to generating application UI, a software application specifies the classes, properties, and values of the objects of the UI and their relationship with one another in a declarative manner, generally referred to as a declarative UI. A declarative UI is implemented by a software developer utilizing a declarative language to specify the tags, attributes, and values that correspond to the classes, properties and values of the objects within the UI. However, unlike programmatic languages, declarative languages conforming to the Standard Generalized Markup Language (SGML), such as the Hypertext Markup Language (HTML) and Extensible Markup Language (XML), are configured to allow the UI objects to be instantiated at run-time by the operating environment. Accordingly, a declarative UI provides more flexibility to the software developer to vary UI objects without requiring a modification of the application software code.
Some declarative languages, such as HTML, utilize a class hierarchy, such as a defined schema, for validating the declarative UI data generated by the software application. One skilled in the relevant art will appreciate that a schema is similar to template that defines the properties of a class in the hierarchy and its relationship to other classes within the hierarchy. FIG. 2 is a block diagram of a class hierarchy 84 illustrating the relationship of classes as superclasses and subclasses of one another. As illustrated in FIG. 2, the class hierarchy 84 includes a class 86 that is at the top node of the class hierarchy. This class is a superclass of classes 88, 90, 92, which are defined to be subclasses of the class 86. Similarly, class 88 is a superclass of class 94, which a subclass of class 88. Each class is defined as having various properties that may be specified. Additionally, a subclass generally inherits all the properties of its superclass.
In one conventional approach to processing some declarative languages, such as HTML, a parser within a software application generating the UI objects, such as an operating environment, utilizes the defined schema to validate whether the various tags and attributes specified within an HTML specification are valid. Although the use of declarative languages facilitate the run-time specification of UI display objects, declarative languages that rely on a defined schema prevents a software developer from modifying or personalizing the class hierarchy. For example, as applied to a declarative UI, a software developer may wish to define additional properties to a class of UI objects or modify existing object properties, generally referred to as extensibility. FIG. 3 is a block diagram of the class hierarchy 84 of FIG. 2 that includes a new subclass 96 of class 94. However, it will be readily understood by one skilled in the relevant art that some conventional declarative languages, such as HTML, do not provide for developer extensibility and become deficient for facilitating dynamic, extensible UI object specification.
Other declarative languages, such as XML, allow a developer to modify the defined schema provided by the operating environment by specifying additional classes having within a schema as illustrated in the “extended” class hierarchy of FIG. 3. Accordingly, a developer, through the software application, could utilize the extended class definitions to specify XML tag, attribute and value data that would correspond to the new class(es). With regard to the use of an extensible declarative language, such as XML, for generation of software application UI, software applications can create customized user interfaces by extending the base UI class hierarchy to define customized classes and generating instance data that specifies tag, attribute and value data related to the extended class
Similar to other declarative languages, the conventional processing of XML instance data requires the instance data to be validated by an XML parser to ensure that the tag, attribute, value data being specified conforms to the class definition defined in the XML schema. More specifically, the XML parser processes the instance data according to the base XML schema to generate the class hierarchy utilized to validate the instance data. In the event the instance data includes tag, attribute and value data related to an extended class, the conventional XML instance data processing procedure requires the instance data to refer to an extended schema that defines the new class(es).
One skilled in the relevant art will appreciate that conventional extensible declarative languages, such as XML, require an extended schema to include not only the additional class(es) being defined and its related properties, but all the other classes associated with the original class hierarchy derived from the base schema. However, requiring an extended schema to include all the classes and their relationship (e.g., superclass/subclass) cab become inefficient and redundant. For example, assume a class hierarchy includes a node class having four properties and two subclasses that each has 5 properties. In order to define an extended class hierarchy that creates a third subclass of the node class having only one property, the extended schema would have to include the definitions of the original node class and the two subclasses as well as the newly added third subclass. With regard to the above example, in the event the original class hierarchy is subsequently modified to alter one of the classes (e.g., the node class or one of the subclasses) not associated with extended class, the extended schema would thereafter be invalid because it did not confirm the most current version of the class hierarchy. Thus, the extended XML would have to be modified each time the base schema is modified, even if the modification to the base schema would not affect the classes in the extended XML schema. Thus, the conventional declarative language method for validating instance data becomes inefficient.
In addition to the deficiencies associated with extensible schema for extensible declarative languages, such as XML, conventional declarative language processing methods do not provide a mechanism for directly instantiating the various objects from the instance data. With reference to an embodiment for instantiating UI objects, the specification of tag, attribute and value instance data does not generate the UI objects corresponding to the data. Instead, a parser validates the data and relies on the application supplying the instance data to cause the validated objects to be generated by the operating environment in a manner defined by the application. Accordingly, the conventional approach is further deficient in not having a central processing method that can also instantiate validated objects.
Thus, there is a need for a method and system for dynamically processing declarative language instance data to validate and instantiate a user interface object hierarchy.